CircleCI 2.0アップグレードをあきらめてCodePipelineでGitHub→S3静的ホスティングのCD環境を作った話
ベルリンのしがひです。クラスメソッドヨーロッパのウェブサイトはS3のスタティックホスティングとCloudFrontを使ったサーバーレス・超低コストな構成になっているのですが、サイトの編集管理ワークフローとして、GitHubとCircleCIを使っていました。
CircleCIはパフォーマンスが大幅に強化されたバージョン2.0が現行で、1.0は2018年8月31日でディスコンされるというアナウンスが昨年のはじめにありました。1.0 --> 2.0のアップグレードは何かボタンを押せばできるというたぐいのものではなく、yamlの書き換えとソース配置の再検討が必要になる大仕事で、見なかったことにしていたら9月になっていました。
早くアップグレードしなさいという圧を感じます。しかしこう言われると、動いているものを変えろというわりには成果が少なく、もっとなんかできるんじゃないか、と、このメッセージを書いた人の意図とは正反対のモチベーションが湧いてきます。ということで、昨年末、CircleCIからCodePipelineへの移行を実施しました。
CodePipelineによるワークフロー
GitHubを含めて全てAWS CodeXXX シリーズにしてAWS内で全てを完結させることも考えたのですが、今回はCircleCIの引退とその代替としてCocePipelineとCodeBuildに集中します。ワークフローを簡単に絵にするとこうなります。
多くの場合レビュアーと承認者は同一人物ですので、GitHub上でPull Requestを作ると同時にMergeも行います。やっていることはS3への差分転送に過ぎないのですが、CodePipelineを中核にワークフローを組み立てることで権限に基づいたムダ、モレのないCI/CD環境を作ることができます。
作ってみた
まずGitHubにログインした状態でCodePipelineからSource指定して、GitHub側で承認しておきます。
パイプラインの実際の中身になるCodeBuildを下記のように組みます。
 |
 |
 |
通知部分の仕掛けを作ります。SNSトピックを作成し、ARNをCodePipelineのコンソール上で指定します。
ステージングブランチとプロダクションブランチをソースにしたこのワークフローを二つ用意し、CodeBuildに実行させるコマンドをymlで記述します。
[gist id="9012820285686c417894b93f6932ba34"]
ステージングバケットは閲覧にIPアドレスによる制限をかけますが、一応robots.txtを配置してクロールを避ける処置を取っているため、syncで除外設定をしています。
動かしてみた
ステージングブランチに制作者がプッシュするとレビュアーに通知が飛びます。
GitHubで変更部分を確認し（ステージングバケットを見ることで見た目の変化も確認できます）、Pull Request、Mergeを進めると下記のようになります。
 |
 |
 |
 |
この裏で先ほどの二つのパイプラインが走っていることが確認できます。
 |
 |
まとめ
S3のスタティックホスティング + CloudFrontの組み合わせは従来では考えられないほどの低コスト・高パフォーマンスの静的サイトを実現できますが、バージョンや権限の管理の確実性と柔軟性を考慮する必要があります。従来それを補完していたがGitHub + CircleCI の組み合わせでできるCI/CD環境が、CodeXXXシリーズでおおよそ代替可能になってきていると言えます。
